home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-atm-classic-ip-01.txt < prev    next >
Text File  |  1993-07-08  |  27KB  |  676 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       Mark Laubach
  8. Request for Comments: DRAFT                 Hewlett-Packard Laboratories
  9. Expires January 5, 1994                                     July 5, 1993
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.                      Classical IP and ARP over ATM
  17.  
  18.  
  19. Status of this Memo
  20.  
  21.    This document is an internet draft. Internet Drafts are working
  22.    documents of the Internet Engineering Task Force (IETF), its Areas,
  23.    and its Working Groups. Note that other groups may also distribute
  24.    working documents as Internet Drafts.
  25.  
  26.    Internet Drafts are draft documents valid for a maximum of six
  27.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  28.    other documents at any time. It is not appropriate to use Internet
  29.    Drafts as reference material or to cite them other than as a "working
  30.    draft" or "work in progress".  Please check the lid-abstracts.txt
  31.    listing contained in the internet-drafts shadow directories on
  32.    nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or
  33.    munnari.oz.au to learn the current status of any Internet Draft.
  34.  
  35. 1.  Abstract
  36.  
  37.    This memo describes an initial application of classical IP and ARP in
  38.    an ATM network environment configured as a Logical IP Subnetwork
  39.    (LIS) as described below and in [1]. This memo does not preclude the
  40.    subsequent development of ATM technology into areas other than an
  41.    LIS; specifically, as single ATM networks grow to replace many
  42.    ethernet local LAN segments and as these networks become globally
  43.    connected, the application of IP and ARP will be treated differently.
  44.    This document considers only the application of ATM a as a direct
  45.    replacement for the "wires" and local LAN segments connecting IP
  46.    end-stations and routers. Issues raised by MAC level bridging are
  47.    beyond the scope of this paper.
  48.  
  49. 3.  Acknowledgment
  50.  
  51.    This memo could not have come into being without the critical review
  52.    from Jim Forster of Cisco Systems, Drew Perkins of FORE Systems, and
  53.    Bryan Lyles, Steve Deering, and Berry Kercheval of XEROX PARC.  The
  54.    concepts and models presented in [1], written by Dave Piscitello and
  55.  
  56.  
  57.  
  58. Laubach                                                         [Page 1]
  59.  
  60. DRAFT                Classical IP and ARP over ATM             July 1993
  61.  
  62.  
  63.    Joseph Lawrence, laid the structural groundwork for this work. This
  64.    document could have not been completed without the expertise of the
  65.    IP over ATM Working Group of the IETF.
  66.  
  67. 4. Conventions
  68.  
  69.    The following language conventions are used in the items of
  70.    specification in this document:
  71.  
  72.    o   MUST, SHALL, or MANDATORY -- the item is an absolute requirement
  73.        of the specification.
  74.  
  75.    o   SHOULD or RECOMMEND -- this item should generally be followed for
  76.        all but exceptional circumstances.
  77.  
  78.    o   MAY or OPTIONAL -- the item is truly optional and may be followed
  79.        or ignored according to the needs of the implementor.
  80.  
  81. 5.  Introduction
  82.  
  83.    The goal of this specification is to allow compatible and
  84.    interoperable implementations for transmitting IP datagrams and ARP
  85.    requests and replies over ATM Adaptation Layer 5 (AAL5)[6].
  86.    Currently, ATM standards are being defined in the ITU-TSS (formally
  87.    CCITT), ANSI and the ATM-FORUM.  ITU-TSS and ANSI are defining
  88.    standards for public ATM networks.  The ATM-FORUM is not a recognized
  89.    standards body, however they are addressing the application of ATM in
  90.    the local environment and there is substantial public involvement.
  91.    It is the intent of this document to follow ITU-TSS standards except
  92.    where the ATM-FORUM provides needed functionality.
  93.  
  94.    Initial deployment of ATM provides a LAN segment replacement for
  95.    ethernet networks and as wire-replacement for dedicated public
  96.    telecommunication lines between IP routers. In the former model,
  97.    local IP routers with one or more ATM interfaces will connect islands
  98.    of local ATM networks. ATM-FORUM compliant addressing will be used
  99.    within these local ATM networks. In the latter model, public ATM
  100.    networks will be used to connect IP routers, which in turn may or may
  101.    not connect to local ATM networks. Public networks will use ITU-TSS
  102.    and ANSI standards for addressing in ATM. ATM-FORUM compliant
  103.    addressing cannot be guaranteed in public ATM networks.
  104.  
  105.    The characteristics and features of ATM networks are different than
  106.    those found in LAN's:
  107.  
  108.    o   ATM provides a virtual circuit switched environment. VC setup may
  109.        be done on either a Permanent Virtual Circuit (PVC) or dynamic
  110.        Switched Virtual Circuit (SVC) basis. SVC call management
  111.  
  112.  
  113.  
  114. Laubach                                                         [Page 2]
  115.  
  116. DRAFT                Classical IP and ARP over ATM             July 1993
  117.  
  118.  
  119.        signalling is performed via Q.93B implementations [7,9].
  120.  
  121.    o   Data to be passed by a VC is segmented into 53 octet quantities
  122.        called cells (5 octets of ATM header and 48 octets of data). ATM
  123.        networks provide very low latency switching, high throughput, and
  124.        the ability to multiplex VC's of differing quality of service.
  125.  
  126.    o   Each VC carries a type which identifies a specific format for the
  127.        exchange of protocol data units (PDU's). These formats are called
  128.        ATM Adaptation Layers (AAL's) and are typed from 1 through 5.
  129.        AAL5 specifies a packet format with a maximum size of 64K user
  130.        data octets. Cells for an AAL5 PDU are transmitted first to last,
  131.        the last cell indicating end of PDU. ATM standards guarantee that
  132.        on a given VC, cell ordering is preserved end-to-end.
  133.  
  134.    o   ATM-FORUM signalling defines point-to-point and point-to-
  135.        multipoint addressing [9].  Multicast service addressing is not
  136.        yet a conformance requirement of the ATM-FORUM.
  137.  
  138.    o   ATM-FORUM local LAN addresses are hardware addresses using the
  139.        same format as NSAP's.
  140.  
  141.    This memo describes the initial deployment of ATM within "classical"
  142.    IP networks as a direct replacement for local area networks
  143.    (ethernets) and for IP links which interconnect routers, either
  144.    within or between administrative domains. The "classical" model here
  145.    refers to the treatment of the ATM host adapter as a networking
  146.    interface to the IP protocol stack.
  147.  
  148.    Characteristics of the classical model are:
  149.  
  150.     o  One default maximum MTU size for the network interface,
  151.        consistent with current implementations.
  152.  
  153.     o  Default LLC/SNAP encapsulation of IP packets, with administrator
  154.        allowed reconfiguration.
  155.  
  156.     o  IP destinations map to VC's via ARP and route lookups, consistent
  157.        with current model.
  158.  
  159.     o  ARP's stay within the LIS, current ARP architecture stays the
  160.        same.
  161.  
  162.     o  One IP subnet used for many hosts/routers. A separate VC is used
  163.        for each host/router pair, one subnet is used for all these VC's.
  164.  
  165.    The "global" ATM model is an evolution of the classical model where
  166.    the ATM network becomes more fully deployed and globally available.
  167.  
  168.  
  169.  
  170. Laubach                                                         [Page 3]
  171.  
  172. DRAFT                Classical IP and ARP over ATM             July 1993
  173.  
  174.  
  175.    In this model, the traditional protocol stack architecture evolves
  176.    allowing applications to map directly on VC's (e.g., TCP and UDP
  177.    ports map directly onto VC's) and ARP mechanisms are no longer bound
  178.    to LIS boundaries as queries and replies may go global.  IP will
  179.    evolve to take advantage of the network services provided by the
  180.    global ATM network.
  181.  
  182.    Characteristics of the global model are:
  183.  
  184.     o  MTU size negotiated per VC via ATM signalling, requires MTU size
  185.        be separated from interface in protocol stack.
  186.  
  187.     o  Encapsulation negotiated per VC via ATM signalling, requires
  188.        common signalling to be implemented and globally available.
  189.  
  190.     o  Any applications map to VC's, requires changes to TCP/UDP/IP to
  191.        allow ports to map directly on to VC's
  192.  
  193.     o  ARP's can go global, ARP architecture needs to change to support
  194.        a robust global client/server model.
  195.  
  196.     o  Differing quality of service (QOS) guarantees will exist on a per
  197.        application and per VC basis.
  198.  
  199.    The deployment of ATM into the internet community is beginning and
  200.    will take several years to implement. During this period, we expect
  201.    deployment to follow traditional IP subnet boundaries for the
  202.    following reasons:
  203.  
  204.     o  Administrators and managers of IP subnetworks will tend to
  205.        initially follow the same models as they currently have deployed.
  206.        The mindset of the community will change slowly over time as ATM
  207.        increases its coverage and builds its credibility.
  208.  
  209.     o  Policy administration practices rely on the security, access,
  210.        routing, and filtering capability of IP Internet gateways: i.e.
  211.        firewalls. ATM will not be allowed to "back-door" these
  212.        mechanisms until ATM provides better management capability than
  213.        the existing services and practices.
  214.  
  215.    This memo details the treatment of the classical model of IP and ARP
  216.    over ATM. There are those would like to have IP-over-ATM begin by
  217.    breaking the classical model - this memo represents the view that we
  218.    must walk before we can run. This memo does not preclude the
  219.    subsequent evolution of ATM networks as they become more globally
  220.    deployed and interconnected and the evolution of TCP and IP to take
  221.    advantage of these changes - these will be the subject of future
  222.    documents. This memo does not address issues related to transparent
  223.  
  224.  
  225.  
  226. Laubach                                                         [Page 4]
  227.  
  228. DRAFT                Classical IP and ARP over ATM             July 1993
  229.  
  230.  
  231.    data link layer interoperability.
  232.  
  233. 6.  IP Subnetwork Configuration
  234.  
  235.    This section describes the scenario for an ATM network that is
  236.    configured with one or more Logical IP Subnetworks (LIS's). The
  237.    scenario considers only directly connected IP hosts or routers
  238.    reachable via switched virtual circuits (SVC's).
  239.  
  240.    In the LIS scenario, each separate administrative entity configures
  241.    its hosts and routers within a closed logical IP subnetwork. Each LIS
  242.    operates and communicates independently of other LIS's over the same
  243.    ATM network. Hosts connected to ATM communicate directly to other
  244.    hosts within the same LIS. Communication to hosts outside of the
  245.    local LIS is provided via an IP router. This router would be a
  246.    station attached to the ATM network that may have been configured as
  247.    a member of two or more LIS's. This configuration results in a number
  248.    of disjoint LIS's operating over the same ATM network. Hosts of
  249.    differing IP subnets would communicate via an intermediate router
  250.    even though a direct virtual circuit between the two hosts may be
  251.    available over the ATM network.
  252.  
  253.    The requirements for IP member stations (hosts, routers) operating in
  254.    an ATM LIS configuration are:
  255.  
  256.    o   All members have the same IP network/subnet number.
  257.  
  258.    o   All stations within an LIS are accessed directly over the ATM
  259.        network.
  260.  
  261.    o   All stations outside of the LIS are accessed via a router.
  262.  
  263.    o   All members of an LIS must have a mechanism for resolving IP
  264.        addresses to ATM addresses via ARP [4] when using SVC's.
  265.  
  266.    o   All members within a LIS MUST be able to communicate with all
  267.        other members in the same LIS; i.e., the topology is fully
  268.        meshed. There should be no administrative restrictions at the ATM
  269.        level that prevent VC's from operating between all pair of
  270.        stations.
  271.  
  272.    The following list identifies a set of ATM specific parameters that
  273.    MUST be implemented in each IP station which would connect to the ATM
  274.    network. The parameter values MUST be user configurable:
  275.  
  276.    o   ATM Hardware Address (atm$ha). The ATM individual address of the
  277.        IP station. Each host must be configured to accept datagrams
  278.        destined for this address
  279.  
  280.  
  281.  
  282. Laubach                                                         [Page 5]
  283.  
  284. DRAFT                Classical IP and ARP over ATM             July 1993
  285.  
  286.  
  287.    o   ATM ARP Request Address (atm$arp-req). The ATM hardware address
  288.        (point-to-point or multicast) to which ARP requests are to be
  289.        sent for the resolution of target protocol addresses to target
  290.        hardware addresses for SVC connections. Three cases are
  291.        available:
  292.  
  293.        1. atm$arp-req is atm$ha, the local machine ATM hardware address.
  294.           The local host may either consult its ARP translation table
  295.           directly, or preferably to support ARP queries by loopback
  296.           internally or externally via the ATM network. In the case of
  297.           an external loopback, a VC is dedicated specifically for ARP
  298.           queries and replies. This case is called the "Loopback ARP"
  299.           model.
  300.  
  301.        2. atm$arp-req is the ATM hardware unicast address of an
  302.           individual ARP server located within the LIS. That server must
  303.           have authoritative responsibility for resolving ARP requests
  304.           all IP stations within the LIS. The VC's connecting IP
  305.           stations to this ARP server are dedicated specifically for ARP
  306.           queries and replies. An individual client connects to the ARP
  307.           server using a point-to-point (unicast) connection. The
  308.           server, upon receiving connections from new clients, will add
  309.           the client address to a single point-to-multipoint group.
  310.           Queries to the server are received on the unicast VC from the
  311.           client. The server responds on the multipoint VC enabling all
  312.           clients receive the reply. This case is called the "ARP
  313.           Server" model.
  314.  
  315.        3. atm$arp-req is an ATM hardware group (multicast) address. If
  316.           the ATM switching fabric supports ATM hardware multicast, then
  317.           a well known VC using the ATM group address local to the LIS
  318.           is dedicated specifically for broadcast ARP queries and
  319.           replies and IP packets sent to the IP broadcast address. The
  320.           ARP query/reply service on all IP stations within the LIS MUST
  321.           be reachable via this address.  This case is called the
  322.           "Multicast ARP" model.
  323.  
  324.    It is RECOMMENDED that the ARP Server model be implemented within an
  325.    LIS. The use of redundant ARP servers however, reachable via a group
  326.    address, is beyond the scope of this document.
  327.  
  328.    The Multicast ARP model is attractive in that it more closely models
  329.    the well known ethernet service of which the community has many years
  330.    of experience. There are some technical details that need to be
  331.    worked out involving the simultaneous transmission of multi-cell AAL5
  332.    PDU's from different sources in a multicast environment and the
  333.    interleaving of PDU's as seen by the receiver. Multicast ARP
  334.    mechanisms should be explored as experience from these experiments
  335.  
  336.  
  337.  
  338. Laubach                                                         [Page 6]
  339.  
  340. DRAFT                Classical IP and ARP over ATM             July 1993
  341.  
  342.  
  343.    can contribute directly to the definition of multicast address
  344.    services in future ATM-FORUM standards activities. The multicast ARP
  345.    model will be more fully detailed in a future document.
  346.  
  347.    ATM hardware addresses are formatted as ATM-FORUM compliant NSAP's
  348.    [9].
  349.  
  350.    ARP request and reply formats are discussed in the section on Address
  351.    Resolution.
  352.  
  353.    It is RECOMMENDED that routers providing LIS functionality over the
  354.    ATM network also support the ability to interconnect differing LIS's.
  355.    Routers that wish to provide interconnection of differing LIS's MUST
  356.    be able to support multiple sets of these parameters (one set for
  357.    each connected LIS) and be able to associate each set of parameters
  358.    with a specific IP network/ subnet number. In addition, it is
  359.    RECOMMENDED that a router be able to provide this multiple LIS
  360.    support with a single physical ATM interface that may have one or
  361.    more individual ATM addresses.
  362.  
  363. 7.  Packet Format
  364.  
  365.    The default packet format for IP datagrams SHALL be the IEEE 802.2
  366.    LLC/SNAP format as described in [2].
  367.  
  368.    This memo recognizes the future development of end-to-end signalling
  369.    within ATM that will allow negotiation of encapsulation method on a
  370.    per-VC basis. Signalling negotiations are beyond the scope of this
  371.    document.
  372.  
  373. 8.  MTU Size
  374.  
  375.    The default MTU size for IP stations operating over the ATM network
  376.    SHALL be 9180 octets. The LLC/SNAP header is 8 octets, therefore the
  377.    maximum ATM AAL5 protocol service unit size will be 9188 octets. In
  378.    classical IP subnets, values other than the default can only be used
  379.    provided that all stations on the LIS can be configured to use the
  380.    non-default value.
  381.  
  382.    The minimum IP MTU size is 576 octets [8]. The LLC/SNAP header is 8
  383.    octets, therefore the minimum ATM AAL5 protocol data unit size will
  384.    be 584 octets.
  385.  
  386.    This memo recognizes the future development of end-to-end signalling
  387.    within ATM that will allow negotiation of MTU size on a per-VC basis.
  388.    Signalling negotiations are beyond the scope of this document.
  389.  
  390. 9.  Address Resolution
  391.  
  392.  
  393.  
  394. Laubach                                                         [Page 7]
  395.  
  396. DRAFT                Classical IP and ARP over ATM             July 1993
  397.  
  398.  
  399.    The dynamic mapping of 32-bit Internet protocol addresses to ATM
  400.    hardware addresses within an LIS SHALL be done via the dynamic
  401.    discovery procedure of the Address Resolution Protocol (ARP) [3].
  402.    The configuration of static mapping or the treatment of ARP within an
  403.    LIS supporting only PVC's is beyond the scope of this document.
  404.  
  405.    Internet addresses are assigned independent of ATM addresses. Each
  406.    host implementation MUST know its own internet and ATM address(es)
  407.    and respond to Address Resolution requests appropriately. Hosts MUST
  408.    also use ARP to map Internet addresses to ATM addresses when needed.
  409.  
  410.    The ARP protocol has several fields that have the following format
  411.    and values:
  412.  
  413.     Data:
  414.         ar$hrd     16 bits   Hardware type
  415.         ar$pro     16 bits   Protocol type
  416.         ar$shln     8 bits   Octet length of source hardware address (m)
  417.         ar$spln     8 bits   Octet length of source protocol address (n)
  418.         ar$op      16 bits   Operation code (request or reply)
  419.         ar$thln     8 bits   Octet length of target hardware address (p)
  420.         ar$tpln     8 bits   Octet length of target protocol address (q)
  421.         ar$sha     moctets   source hardware address
  422.         ar$spa     noctets   source protocol address
  423.         ar$tha     poctets   target hardware address
  424.         ar$tpa     qoctets   target protocol address
  425.  
  426.      Where:
  427.         ar$hrd  -  assigned to NSAP address family and is dd decimal
  428.                    (0x00nn) [4].
  429.  
  430.         ar$pro  -  see Assigned Numbers for protocol type number for
  431.                    the protocol using ARP. (IP is 0x0800).
  432.  
  433.         ar$shln -  length of the source hardware NSAP address length.
  434.  
  435.         ar$spln -  length in bytes of the source protocol address. For
  436.                    IP ar$spln is 4.
  437.  
  438.         ar$op   -  1 for request and 2 for reply
  439.  
  440.         ar$thln -  length of the target hardware NSAP address length.
  441.  
  442.         ar$tpln -  length in bytes of the target protocol address. For
  443.                    IP ar$tpln is 4.
  444.  
  445.         ar$sha  -  source NSAP address.
  446.  
  447.  
  448.  
  449.  
  450. Laubach                                                         [Page 8]
  451.  
  452. DRAFT                Classical IP and ARP over ATM             July 1993
  453.  
  454.  
  455.         ar$spa  -  source protocol address.
  456.  
  457.         ar$tha  -  target NSAP address.
  458.  
  459.         ar$tpa  -  target protocol address.
  460.  
  461.    The ATM hardware addresses in ARP packets (ar$sha, ar$tha) SHALL be
  462.    ATM-FORUM specified NSAP addresses [9].
  463.  
  464.    The same NSAP encoding SHALL be used within an LIS and replies will
  465.    use the same encoding as queries. For example, NSAP's may encode IEEE
  466.    48-bit MAC addresses or may encode E.164 addresses. Within the LIS
  467.    either IEEE MAC or E.164 hardware addresses may be used but not both.
  468.  
  469.    ARP packets are to be encoded in AAL5 PDU's using LLC/SNAP
  470.    encapsulation. The format of the AAL5 CPCS-SDU payload field for
  471.    routed non-ISO PDU's is:
  472.  
  473.                Payload Format for Routed non-ISO PDU's
  474.                +------------------------------+
  475.                |        LLC 0xAA-AA-03        |
  476.                +------------------------------+
  477.                |        OUI 0x00-00-00        |
  478.                +------------------------------+
  479.                |     Ethertype 0x08-06        |
  480.                +------------------------------+
  481.                |                              |
  482.                |         ARP Packet           |
  483.                |                              |
  484.                +------------------------------+
  485.  
  486.    The LLC value of 0xAA-AA-03 (3 bytes) indicates the presence of a
  487.    SNAP header.
  488.  
  489.    The OUI value of 0x00-00-00 (3 bytes) indicates that the following
  490.    two-bytes is an ethertype.
  491.  
  492.    The Ethertype value of 0x08-06 (2 bytes) indicates ARP [4].
  493.  
  494.    The total size of the LLC/SNAP header is 8-bytes fixed length. This
  495.    aligns the start of the ARP packet on a 64-bit boundary relative to
  496.    the start of the AAL5 SDU.
  497.  
  498.    The LLC/SNAP encapsulation for ARP presented here is consistent with
  499.    the treatment of multiprotocol encapsulation of IP over ATM AAL5 as
  500.    specified in [2] and in the format of ARP over IEEE 802 networks as
  501.    specified in [5].
  502.  
  503.  
  504.  
  505.  
  506. Laubach                                                         [Page 9]
  507.  
  508. DRAFT                Classical IP and ARP over ATM             July 1993
  509.  
  510.  
  511.    Traditionally, ARP requests are broadcast to all directly connected
  512.    IP stations within a LIS. It is conceivable in the future that larger
  513.    scaled ATM networks may "broadcast" ARP requests to destinations
  514.    outside the originating LIS, perhaps even globally; issues raised by
  515.    broadcasting outside the LIS or by a global ARP mechanism are beyond
  516.    the scope of this document.
  517.  
  518. 10.  IP Broadcast Address
  519.  
  520.    ATM hardware multicast service addressing is not yet a conformance
  521.    requirement of the ATM-FORUM. As such, there is no consistent
  522.    facility in local area network ATM switches for hardware multicast
  523.    addressing.  Experimentation with ATM multicast addresses in the
  524.    Internet community however, must be supported.  The ATM-FORUM does
  525.    specify point-to-point and point-to-multipoint addressing [9]. The
  526.    following scenarios apply to the multicast and non-multicast
  527.    situations:
  528.  
  529.    1.  ATM multicast available: if the switch fabric connecting the host
  530.        ATM interface supports multicast, then the Internet broadcast
  531.        address (the address on that network with a host part of all
  532.        binary ones) MUST map to an ATM group address that includes all
  533.        IP stations within the LIS.
  534.  
  535.    2.  No ATM multicast support: the Internet broadcast address MUST map
  536.        to atm$arp-req, and atm$arp-req MUST either map to the local IP
  537.        host ATM hardware address or the ATM hardware address of an ARP
  538.        server located within the LIS, if available.  If the LIS is
  539.        operating in the ARP Server model, the station acting as the ARP
  540.        server must relay IP packets received on an ARP unicast query VC
  541.        onto the point-to-multipoint ARP reply VC.
  542.  
  543.    In all cases, encapsulated IP packets sent to the IP broadcast
  544.    address may be received on the ARP query VC by any station. This
  545.    requires that IP packets sent to the IP broadcast address use
  546.    LLC/SNAP encoding and that all stations examine the value of
  547.    ethertype in the LLC/SNAP header and process IP versus ARP
  548.    accordingly on all packets received on this VC.
  549.  
  550. 11.  IP Multicast Address
  551.  
  552.    IP multicast address mappings to ATM point-to-multipoint or group
  553.    addresses are not discussed in this memo.
  554.  
  555. 12.  Security
  556.  
  557.    Security issues are not discussed in this memo.
  558.  
  559.  
  560.  
  561.  
  562. Laubach                                                        [Page 10]
  563.  
  564. DRAFT                Classical IP and ARP over ATM             July 1993
  565.  
  566.  
  567.    This memo recognizes the future development of ATM and IP facilities
  568.    for authenticated call setup, authenticated end-to-end application
  569.    knowledge, and data encryption as being required services for
  570.    globally connected ATM networks. These future security facilities and
  571.    their use by IP networks are beyond the scope of this document.
  572.  
  573. 13.  Open Issues
  574.  
  575.    There are some open issues:
  576.  
  577.    o   A proposal was put before the Internet Assigned Numbers Authority
  578.        to approve a request to create an ARP hardware type of "NSAP
  579.        family address".  IANA has not responded as of this date.  My
  580.        hopes are that we can get an ARP type created now that will cover
  581.        NSAP's for all time.
  582.  
  583.    o   Well known ATM hardware address(es) for ARP servers?  It would be
  584.        very handy if we came up with a set of well known ATM addresses
  585.        for ARP services.  We should probably have well-known PVC numbers
  586.        for a non-SVC environment also.
  587.  
  588.    o   Interim Local Management Interface (ILMI) services will not be
  589.        generally implemented by some providers and vendors and will not
  590.        be used to obtain the ATM address network prefix from the
  591.        network. Meta-signalling does provide some of this functionality
  592.        and in the future we need to document the options.
  593.  
  594. REFERENCES
  595.  
  596.    [1] Piscitello, D., and Lawrence, J., "IP and ARP over the SMDS
  597.        Service", RFC1209, USC/Information Sciences Institute, March
  598.        1991.
  599.  
  600.    [2] Heinanen, Juha, "Multiprotocol Encapsulation over ATM Adaptation
  601.        Layer 5", work in progress, IETF IP over ATM Working Group,
  602.        February 1993.
  603.  
  604.    [3] Plummer, D., "An Ethernet Address Resolution Protocol - or -
  605.        Converting Network Addresses to 48.bit Ethernet Address for
  606.        Transmission on Ethernet Hardware", RFC 826, MIT, November 1982.
  607.  
  608.    [4] Reynolds, J., and Postel, J., "Assigned Numbers", RFC1340, USC/
  609.        Information Sciences Institute, July 1992.
  610.  
  611.    [5] Postel, J., and Reynolds, J., "A Standard for the Transmission of
  612.        IP Datagrams over IEEE 802 Networks", RFC1042, USC/Information
  613.        Sciences Institute, February 1988.
  614.  
  615.  
  616.  
  617.  
  618. Laubach                                                        [Page 11]
  619.  
  620. DRAFT                Classical IP and ARP over ATM             July 1993
  621.  
  622.  
  623.    [6] CCITT, "Draft Recommendation I.363", CCITT Study Group XVIII,
  624.        Geneva, 19-29 January 1993.
  625.  
  626.    [7] CCITT, "Draft text for Q.93B", CCITT Study Group XI, 23 September
  627.        - 2 October 1992.
  628.  
  629.    [8] Braden, R., "Requirements for Internet Hosts -- Communication
  630.        Layers", RFC1122, USC/Information Sciences Institute, October
  631.        1989.
  632.  
  633.    [9] ATM-FORUM, "ATM User-Network Interface Specification Version 3.0.
  634.        (DRAFT)", June 1993.
  635.  
  636. Author's Address
  637.  
  638.    Mark Laubach
  639.    Hewlett-Packard Laboratories
  640.    1501 Page Mill Road
  641.    Palo Alto, CA 94304
  642.  
  643.    Phone: 415.857.3513             FAX: 415.857.8526
  644.    EMail: laubach@hpl.hp.com
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Laubach                                                        [Page 12]
  675.  
  676.